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(57) Abstract: EBPP systems and processes which employ a common document model/data model to accommodate the interests 
and preferences of billcrs, customers, financial institutions, other EBPP organizations and others in the context EBPP specifically 
and electronic commerce more generally. The common document model/data model allows the biller to outsource billing activities 
to the EBPP organization while retaining control over the billing information or how or where bills will be presented. Billers are 
incentivized to use the system because they avoid the expense and effort of building a customized system in house, but get the same 
advantages of an in house system while leveraging the expertise of an outside EBPP organization who operates across a range of 
industries, 
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customers, geographical locations and financial fields. The systems also allow billcrs enhanced opportunities to build brand and 
customer relationships not offered in paper-based billing systems. Customers arc inccnlivizeri to use the system because they can 
pay all or most all of their bills in one place, the place of their choice with bills presented how they choose, and because they may 
communicate more effectively with billers if and when things go wrong rather than wasting inordinate time on the telephone attempt- 
ing to sort things out with uninformed people as is often the case in paper based billing systems where the relevant data never seems 
to catch iip with the billcr's customer service personnel. The result is a ubiquitous liBPP presence that makes everyone 1 s life easier 
and better by reducing bill generation and payment burdens. 
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ELECTRONIC BILL PRESENTMENT AND PAYMENT SYSTEMS AND 

PROCESSES 

The present invention relates generally to electronic commerce, and more 
5 particularly to methods and systems for providing end-to-end electronic bill 
presentment and payment systems, processes and functionality. 

Background of the Invention 
Some people think dealing with bills is not fun. They consider it a burden 

10 which they would love to lift from their shoulders or at least reduce. Billers do not 
like having to create and send them and bill payers do not like paying them. But 
billing consumers for goods and services has always been a necessary exercise and 
transaction cost of engaging in credit-based commerce. Traditional paper-based 
billing processes seek three major objectives: to (1) deliver bills to the customer 

15 base reliably (2) at minimum cost and (3) in a manner that causes quick payment. 
Although as reliable as the postal system, conventional paper-based billing is 
expensive and gives the customer a significant float thus depriving the biller of the 
time value of money. For example, a company with 100,000 accounts which are 
billed on a monthly basis may spend over two million dollars a year in paper-based 

20 billing expenses; a single paper based billing transaction can cost between one and 
two dollars. Much of this expense stems from the cost of materials, printing, 
postage, and manual processing of the paper bills, inserts and envelopes. 

The time delay associated with paper based billing can be particularly 
vexsome to small billers and non-recurrent billers who tend to rely more heavily on 

25 cash flow. For larger billers such as a utility whose average billed amount is $75 

with a customer population of 100,000, the float assuming a 6 day round trip through 
the postal system and interest at the rate of 8% is more than $1 15,000 per year. 

Paper-based billing can also deprive billers of an opportunity to build brand. 
Although many paper billers include various types of marketing inserts with their bills 

30 in an attempt to use the billing activity as an additional opportunity to build brand and 
customer relationships, those materials cannot be targeted as effectively as in an 
interactive session. For instance, billers do not have significant realistic control over 
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the circumstances under which, or whether, a consumer views particular inserts. In 
fact, studies have shown that many consumers disregard such inserts altogether. 

Electronic bill presentment and payment (EBPP) arose with the advent of the 
Internet because it addresses three needs of billers. First, it reduces billing cost. 

5 Second, it allows more effective marketing through the billing process than paper- 
based billing. Third, it allows better customer relationship management than with 
paper-based billing. Instead of preparing and mailing paper bills, EBPP enables 
businesses to publish, distribute and/or present bills electronically on web pages. 
Instead of writing checks and applying stamps, consumers have the opportunity to 

10 pay bills such as by an electronic credit card charge or direct bank draft. The biller 
benefits by avoiding the cost of generating and mailing paper bills, and by avoiding 
the payment float occasioned by two-way mail delay and other delays in paper- 
based remittance. The customer benefits with the added convenience of conducting 
transactions online, and the opportunity to pay many or all bills on one site or in one 

15 virtual space. The biller has the opportunity to present customized content on the 
screenface with the bill, without having to foot the extra printing and insertion cost 
associated with paper inserts. The biller can stay in closer communication with the 
customer via electronic mail and other electronic techniques, and can communicate 
interactively. 

20 Nothing is free, however, and there are costs associated with moving from 

paper-based billing to EBPP. EBPP in any event presents significant hardware, 
software, security and storage issues, as well as significant human resources 
issues. Outsourcing these issues is a viable alternative for an organization that does 
not desire to custom build a proprietary EBPP function or whose size or economic 

25 base does not cost justify such an in-house solution, but outsourcing always 

sacrifices control of the system, of where and how the bills are presented, and over 
the potential to build brand and customer relationships through the billing process. 
In short, across the population of various types of conventional EBPP architectures 
and systems, there is always a tradeoff between complexity and control over the 

30 process. In-house systems tend to be complex and expensive, but give maximum 
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real time control over the process. Outsourcing solutions can be less expensive to 
pursue, but conventionally only by giving up significant real time control. 

Real time control over the billing process is of massive importance, because it 
allows building of brand and customer relationships. For example, special discounts 
5 can be applied online in real time if the customer pays in a certain period, and the 
account immediately adjusted and balanced. Specially targeted inserts can be 
presented on screen with the bill according to a particular group in which the 
customer fits, where he or she is geographically located, or according to any other 
desired demographic data or category. Time sensitive content can be displayed with 
10 the bill, such as promotions relating to events which occur on certain days, limited 
time only sales or markieting efforts, or any other time sensitive information which 
obviously needs to be added, deleted or supplanted when the relevant time starts or 
expires. 

In one common approach to EBPP, for example, which is often referred to as 

15 the custom development method, billers create a proprietary electronic billing system 
and link it to a third-party for payment processing. Because custom development is 
mostly an internal EBPP solution, it gives billers the advantage of tight control over 
the billing system. However, this type of solution is expensive. Not only is it a 
technology risk because billers lose the flexibility to adapt to other EBPP standards, 

20 but it also requires a substantial commitment of manpower, infrastructure and 

consultant resources for planning, development and implementation. Among other 
things, merely obtaining a license to run the relational database application for 
managing billing information is often viewed as prohibitive, especially for smaller 
billers. Furthermore, such systems innately discourage consumer use or popularity, 

25 since the consumer is required to log onto and initiate a session on a separate site, 
with different passwords and different logon procedures, for each different bill the 
consumer wishes to pay. 

One example of the custom development or "in-house" approach to EBPP is 
the direct rendering approach. In the direct rendering approach, billers merely 

30 present electronic representations of the paper bills to consumers. For example, the 
paper bills may be electronically "redrawn" via electronic scanning and then digitally 
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presented to consumers in any standard electronic format such as an HTML web 
page or a PDF file. However, because the information contained in the paper bills is 
not extracted from the document, billers are unable to perform any useful processing 
of the electronic bill or apply any marketing or business rules other than merely 
5 electronically presenting the bill and accepting payment. For instance, the biller is 
not able to query a database and obtain a report of all bills with a balance over 
$40.00. Since images are stored rather than data, for the bills to be formatted 
differently for another type of platform such as for a personal digital assistant or 
cellphone rather than for a personal computer, they must be electronically 

10 rerendered. Bills cannot be grouped according to demographic or other target 
marketed parameters for customized advertising, promotional or brand building 
content or graphics. Customer service based on accessing a database of the 
information in response to customer inquires is precluded. Reports cannot be 
prepared for the biller to show aging or other information about status of bills. The 

15 direct rendering is perhaps the most static of EBPP systems. 

A second approach to EBPP is the front-end rendering approach. In front- 
end rendering, parsing rules are applied to a billing stream at the time the billing 
stream is loaded. The rules transform the data into a generic format for processing 
and storage, such as using XML, but only in a snapshot fashion at parsing time and 

20 without the ability to change bills or otherwise operate on the data stored in the 

database. Thus, although the front-end rendering approach does enable billers to 
perform certain load time decisions and rules, it tends to create a static rather than 
dynamic set of data with concomitant limitations. It tends to focus on parsing and 
presentment of bills, with less emphasis on the processing aspect. It tends to be 

25 fast, even if not dynamic. Because this EBPP paradigm merely shoots a snapshot 
at processing time, billers cannot make modifications to the electronic bill at the time 
of presentment, for example. It cannot create and use various report and view 
formats via which to view and operate on the billing data stored in the database. It 
cannot create and set permissions for access to and processing of such data. In 

30 addition to loss of control of this sort and other sorts, the front-end rendering 
approach is expensive due to substantial implementation costs and because it 
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requires the use of multiple application program interfaces to handle the electronic 
billing data. A central reason for loss of control of data once the biller stream has 
been parsed is that the biller-side data has not been decoupled sufficiently from the 
presentment-side data. 
5 A third conventional EBPP approach, which is referred to as the consolidator 

approach trades control of the billing interface and branding opportunity for a 
reduction in cost, risk, and internal staffing by outsourcing the EBPP to a third party 
consolidator. Here, the electronic payment processor takes on a lock box function of 
holding and moving cash during billing and payment The payment processor 
10 performs an aggregation function by presenting multiple bitters' statements at a 

single, consolidating web site. Not only does interposition of the consolidator and its 
interface between billers and consumers interrupt any existing relationship and 
potential to build brand, but it also precludes exploitation of new biller opportunities 
to interact with consumers. 
15 In addition to the problems already mentioned, existing EBPP systems and 

processes have various other disadvantages. For example, they remain an 
expensive option for most billers who lack sufficient economies of scale necessary to 
overcome the high fixed cost of implementation. These EBPP methods, which 
primarily focus on reducing biller costs, also often fail to address the issue of 
20 consumer convenience adequately, much less to provide effective incentives for 
consumer adoption. 

Furthermore, conventional EBPP approaches often require redundant 
resources supported by multiple entities and consequently waste processing and 
transport resources. For example, using existing EBPP methods, if a consumer 
25 desires to pay AT&T bills electronically at a website such as Yahoo.com., the 

following occurs. First, the consumer requests that Yahoo.com receive the AT&T bill 
and send it to the consumer. Then, assuming AT&T partners with an electronic 
payment facilitator such as CheckFree, Yahoo.com makes a request to CheckFree. 
Finally, CheckFree initiates the request to AT&T. Because each of these entities is 
30 independent, each requires its own resident database and other support 
functionality. Such conventional EBPP approaches leave open significant 
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opportunity to increase efficiency and effectiveness by reducing throughput, 
redundancy and concurrency tasks and Issues. 

Summary of the Invention 
5 The present invention provides end-to-end electronic bill presentment and 

payment systems and processes which seek to be the Switzerland of EBPP 
sources. Such systems and processes speak in a lingua franca to enable any and 
all billers to interface with any and all banks and other financial institutions, payment 
facilitators, consumers, web portals and / or bill presenters and other entities in order 

10 to accomplish bill presentment and payment. 

Core to systems and processes according to the present invention are 
databases which store billing data and their metadata or attributes according to a 
lingua franca that is easily, efficiently and accurately understood and traded on 
anywhere on the Internet or any other data network. Systems and processes 

15 according to the present invention seek to transform billing data from any biller, 
customer or financial institution into a lingua franca or a form that allows quick 
conversion into the lingua franca. In some ways, systems and processes according 
to the present invention treat data similar to how packages are treated in the FEDEX 
system. There, all packages go via air to Memphis where they are collected and 

20 sorted in the middle of the night according to highly automated processes, and then 
launched on the correct aircraft for direction to their destination. Although intuition 
suggests that FEDEX should send an Atlanta shipper's package directed to an 
Atlanta address directly to that address rather than to Memphis and back overnight, 
studies showed that efficiency was served by instead always applying a highly 

25 automated and efficient common collection, storage and distribution process in 
Memphis, even if it did require package travel over greater geographic distance. 
Similarly, systems and processes according to the present invention transform data 
and its attributes into a form that can be stored in a common document storage 
model before operating on it. That model allows efficient and accurate access, 

30 processing, and distribution via a lingua franca such as XML, for access and use by 
the billers, financial institutions, other EBPP processors, and of course the 
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customers. In some ways, the common document model / storage models 
according to the present invention can be compared to Memphis in the FEDEX 
system or the hub and spoke architecture that airlines use for efficient "processing" 
of passengers to their destinations. 
5 * Systems and processes according to the present invention thus use common 
document models and storage models which are generic in some ways and not 
confined to a particular industry, biller, or type of customer. The models 
accommodate a range of billers, bill types, record types, presentation types, 
presentation media types, biller output data streams, and data interchange protocols 

10 and processes. 

According to a preferred embodiment of the present invention, a data stream 
from a biller, which may be a print stream, data interchange stream or any other 
sequence of data, is the subject of a rules application process. The rules application 
process uses a special rules development language that allows a quasi-skilled 

15 specialist in minimum time to generate a translator that parses the biller's data 

stream into a common document model tree. In the tree, which may be based on 
XML or successors to it, the data and their attributes are mapped into nodes which 
fit the common document model for storage in the database. Because of the 
generic and universal nature in which the billing data and its attributes are stored, 

20 the database can be coupled to presentment processors, such as via XML, that may 
include style sheets and other applications that transform the stored data into 
whatever desired form and format to support bill presentment wherever and 
whenever desired. 

Such systems can provide billers a complete end-to-end solution for 

25 electronic bill presentment and payment. The biller's data may be transformed 
efficiently and effectively using the rules definition language into data and its 
attributes that can be stored in a manner that allow the biller new opportunities not 
available in conventional EBPP systems. These stem from the fact that the biller 
can access the billing data and attributes stored in databases according to the 

30 present invention in order (1) to operate on it; (2) to query it for information; (3) to 
control how it will be presented to customers and with what other information such 
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as brand building or customer relationship building information; and (4) to access, 
use and perhaps change it while communicating with customers such as via a help 
desk or customer service lines. Thus, according to the present invention, the bitter 
may have "offloaded" the data to an outsource for EBPP, but without losing the 
opportunity to access and operate on the billing data, and to control in real time the 
data that will be presented to customers in the form of bills as well as the look and 
feel according to which the bills are presented, to obtain reports about bill status, to 
help effectuate the payment process, to categorize or group bills or customers for 
various purposes such as adding demographically or other based content, and for 
other purposes. Because of the universality of its structure, the billers can control 
from a billing console functionality how the bills and billing data will be presented on 
any desired platform using any desired applications, formats and protocols, via 
presentment engines that include style sheets, translators, processors or other 
techniques which allow efficient and ready transformation into a state ready for use 
by such platforms, applications, formats and protocols. For example, for a single 
biller, the database can simultaneously present bills for different customers from a 
single batch of bills in various spoken languages, on HTML based browsers, on OFX 
supported applications, or in any other way desired by any biller or customer. 

EBPP systems and processes according to the present invention for the first 
time promote EBPP aggregation. From the biller's point of view, these systems and 
processes allow many types of billers to have their bills processed, presented and 
paid using a single source using the common document model / storage model. 
Each of such billers is incentivized to use this source, because with it, they can 
outsource their billing problems but still maintain control over their billing data and 
how it is presented. Thus, value propositions for the biller from systems and 
processes according to the present invention include: 

a. end to end electronic billing services which can be outsourced 
relatively inexpensively without loss of control over bill processing, presentment or 
payment; 

b. establish a base for entering the electronic commerce field; 
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c. leverage brand building, customer relationship building and marketing 
opportunities offered by these EBPP systems, by unlimited ability to control the way 
the bill looks, what is contained in it and why, and how and according to what terms 
it can be paid; 

d. use existing payment relationships with minimum interruption or 
inconvenience to financial institutions or customers; 

e. deliver bills wherever the customer wants; 

f. establish an online presence; 

g. unpack the biller's own information, support HTML presentation so that 
for the first time, biller's own employees may access it and use it to service 
customers; 

h. promote quick payment; 

i. avoid the costs and human resources requirements of doing these 
things in house; 

j. cost reduction over paper based billing; 

k. pay as you use; avoid capital costs of in house billing system; 

I. leverage marketing and EBPP expertise and talent of EBPP processor 
who operates across a range of industries and customers and is thus current with 
latest trends; 

From the customer's point of view, because of the common document model / 
storage model, such systems and processes can present and enable payment of 
bills ubiquitously — customers can have their bills presented and paid on web 
portals, on their home financial application, via electronic mail, or wherever else they 
desire. Because billers are incentivized to use the systems and processes, 
customers can pay all or most all of their bills in one place, but in a manner where 
each bill is presented to the customer in a way that is specially tailored to the 
customer with graphics, advertising, and other information that has been 
demographically proven to connect with that particular customer. Value propositions 
for the customer from EBPP systems according to the present invention include: 

a. bills delivered to place, site, space, application, of choice; 

b. pay all or most bills in one place; 

9 


WO 01/77938 PCTYUS01/10J38 

c. convenience over collecting and paying paper bills; 

d. leverage convenience for institutional customers; for example, a 
university with thousands of electric meters can now receive one bill with the meters 
netted up, to effectuate a single payment bill thus avoiding the significant costs of 

5 preparing and paying thousands of bills; 

e. reminders if desired; 

f. ability to receive relevant and demographically tailored and targeted 
information of value from the biller; 

g. cost and convenience over buying stamps and depositing paid bills in 
10 the mail. 

Financial institutions connected to such systems find that they can leverage 
off the time value of money because quick payment means more accrued debt on 
which interest accrues. In short, every entity in the connected environment has 
incentive to use systems and processes according to the present invention, chiefly 
15 because they can be connected and transact in a way where each retains maximum 
control, gets maximum useful information, and transacts with minimum inefficiency 
and overhead. 

Brief Description of the Drawings 

Figure 1 is a diagram illustrating external connectivity of a preferred 
20 embodiment of an electronic bill presentment and payment platform according to the 
present invention. 

Figure 2 is a diagram illustrating the architecture of the platform of Figure 1. 

Figure 3 is a general level diagram showing components of and processes 
carried out by preferred embodiments of systems and processes according to the 
25 present invention. 

Figure 4 is a diagram showing components of and biller data input processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 

Figure 5 is a diagram showing components of and database load processes 
30 carried out by preferred embodiments of systems and processes according to the 
present invention. 

10 
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Figure 6 is a diagram showing components of and bill presentment processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 

Figure 7 is a sign in screen shot of a biller interface generated by a preferred 
5 embodiment of systems and processes of the present invention. 

Figure 8 is a user selection screen shot of a bilier interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 9 is a new user creation screen shot of a biller interface generated by 
a preferred embodiment of systems and processes of the present invention. 
10 Figure 1 0A is a general parameters customization screen shot of a biller 

interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 10B is one portion of an enrollment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
15 processes of the present invention. 

Figure 10C is another portion of an enrollment parameters customization 
screen shot of a biller interface generated by a preferred embodiment of systems 
and processes of the present invention. 

Figure 10D is a further portion of an enrollment parameters customization 
20 screen shot of a biller interface generated by a preferred embodiment of systems 
and processes of the present invention. 

Figure 10E is a parsing and loading parameters customization screen shot of 
a biller interface generated by a preferred embodiment of systems and processes of 
the present invention. 

25 Figure 10F is a bill presentment parameters customization screen shot of a 

biller interface generated by a preferred embodiment of systems and processes of 
the present invention. 

Figure 1 0G is a portion of a payment parameters customization screen shot 
of a biller interface generated by a preferred embodiment of systems and processes 

30 of the present invention. 
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Figure 10H is another portion of a payment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 

Figure 10Ms a further portion of a payment parameters customization screen 
5 shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 

Figure 10J is a reporting parameters customization screen shot of a biller 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

1° Figure 11 is a quality assurance screen shot of a biller interface generated by 

a preferred embodiment of systems and processes of the present invention. 

Figure 12 is another quality assurance screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

15 Figure 13 is a bill publishing screen shot of a biller interface generated by a 

preferred embodiment of systems and processes of the present invention. 

Figure 14A is a request consolidation screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

20 Figure 14B is another quality assurance screen shot of a biller interface 

generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 15 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
25 invention. 

Figure 16 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 17 is an outbound document control screen shot of a biller interface 
30 generated by a preferred embodiment of systems and processes of the present 
invention. 
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Figure 18 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 19 is a mass email screen shot of a biller interface generated by a 
5 preferred embodiment of systems and processes of the present invention. 

Figure 20 is a compose mass email screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 21 is a news and messages screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 
10 Figure 22 is a virtual group maintenance screen shot of a biller interface 

generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 23 is a virtual group edit screen shot of a biller interface generated by 
a preferred embodiment of systems and processes of the present invention. 
15 Figure 24 is a customer bills screen shot of a biller interface generated by a 

preferred embodiment of systems and processes of the present invention; 

Figure 25 is a customer accounts screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 26 is a customer profile screen shot of a biller interface generated by a 
20 preferred embodiment of systems and processes of the present invention. 

Figure 27 is a customer personal information screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 28 is a customer agreement screen shot of a biller interface generated 
25 by a preferred embodiment of systems and processes of the present invention. 

Figure 29 is a customer payment instruments screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 30 is a customer scheduled payment screen shot of a biller interface 
30 generated by a preferred embodiment of systems and processes of the present 
invention. 
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Figure 31 is a customer service email screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 32 is a customer service notes screen shot of a biller interface 
5 generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 33 is a diagram showing various functionalities which may be included 
in a preferred embodiment of systems and processes according to the present 
invention. 

10 Figure 34 is a diagram showing external connectivity of an alternative 

embodiment of systems and processes according to the present invention. 

Figure 35 is an agent sign in screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 36 is a policy number search screen shot of an agent interface 
15 generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 37 is a customer name search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

20 Figure 38 is a policy information screen shot of an agent interface generated 

by a preferred embodiment of systems and processes of the present invention. 

Figure 39 is a payment history display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

25 Figure 40A is a customer policy display screen shot of an agent interface 

generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 40B is another customer policy display screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
30 present invention. 
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Figure 41 is a policy payment display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 42 is a policy payment details screen shot of an agent interface 
5 generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 43 is another policy payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

10 Figure 44 is an agent customer service note screen shot of an agent interface 

generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 45 is a customer name search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
15 invention. 

Figure 46 is a policy information screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 47 is a multiple payment search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
20 invention. 

Figure 48 is a multiple payment search results screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 49 is a customer policy payment screen shot of an agent interface 
25 generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 50 is another customer policy payment screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 
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Figure 51 is an operation successful notification screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 52 is a policy list screen shot of an agent interface generated by a 
5 preferred embodiment of systems and processes of the present invention. 

Figure 53A is a portion of a customer policy display screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 53B is another portion of a customer policy display screen shot of an 
10 agent interface generated by a preferred embodiment of systems and processes of 
the present invention. 

Figure 54 is a new policy payment screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

15 Figure 55 is another new policy payment screen shot of an agent interface 

generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 56 is a new policy payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
20 invention. 

Figure 57 is another new policy payment details screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 58 is a customer notes screen shot of an agent interface generated by 
25 a preferred embodiment of systems and processes of the present invention. 

Figure 59 is a place note screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 60 is a cash report search screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 
30 Figure 61 is cash report screen shot of an agent interface generated by a 

preferred embodiment of systems and processes of the present invention. 
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Figure 62 is an agency payment screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 63 is an agency payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
5 invention. 

Figure 64 is another agency payment details screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 65 is an additional reports screen shot of an agent interface generated 
10 by a preferred embodiment of systems and processes of the present invention. 

Figure 66 is a diagram showing processes for virtual groups according to a 
preferred embodiment of the present invention. 

Detailed Description 

15 Figure 1 shows connectivity of a preferred embodiment of a platform 10 of 

electronic bill presentment and payment processes and systems according to the 
present invention to other entities. Platform 10 can interface with, among other 
external entities, billers 12, banks and other financial institutions 14, payment 
facilitators or aggregators 16, consumers 18, and web portals, applications and / or 

20 bill presenters 20. Platform 10 can provide billers 12 a complete end-to-end solution 
for electronic bill presentment and payment that also accommodates the interests 
and convenience of consumers 18. Billers 12 can be any organization or 
institution that engages in paper based billing or conventional EBPP, or any other 
organization that has need or desire to engage in the sort of aggregated electronic 

25 commerce offered by systems and processes according to the present invention. Oil 
companies; insurance companies, utilities, telecommunications companies, 
communication service providers, retail institutions, credit organizations and others 
similarly situated fit within the broad and limitless profile of organizations who can 
leverage from systems and processes according to the present invention. 

30 Financial institutions 14 which may connect, interact and/or transact with 

systems and processes according to the present invention include banks, credit 
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organizations, brokerages, insurance companies, and any other organization which 
can have a need or desire to interact with systems and processes according to the 
present invention to help effectuate electronic bill presentment and/or payment, or to 
enhance or build their own online presence for marketing and any other desired 
purpose. 

Payment facilitators 16 can include other EBPP facilitators or organizations, 
credit card companies, credit unions, banks, or any other organization which can 
have a need or desire to interact with systems and processes according to the 
present invention to help effectuate electronic bill presentment and/or payment, or to 
enhance or build their own online presence for marketing and any other desired 
purpose. 

Consumers 18 can be individuals, businesses, educational institutions, or any 
other entity that pays bills. 

Presenters 20 can be web portals, financial applications on a consumer's 18 
system, web sites specifically supported for the purpose of EBPP, the site of biller 
12, or any other desired interface where a bill can be presented. 

Platform 1 0 may take the form of a network of desired platforms, computers, 
or other functionality, located in one or more geographical locations, running any 
desired operating systems and applications. In the preferred embodiment, platform 
1 0 is implemented on a Solaris operating system using an Oracle database and 
CORBA firmware and is configured in a scaleable and fault tolerant environment. 
Platform 10 may be connected to billers 12, financial institutions 14, payment 
facilitators 16, presenters 20 and any other desired entity via public or private 
packet-switched or other data networks including the Internet, circuit switched 
networks such as the public switched telephone network, wireless networks, or any 
other desired communications infrastructure 21 . 

Referring to Figure 2, platform 10 may accept biller data 23 in any form or 
format supplied by any biller 12. Biller data 23 may be a print stream or it may 
otherwise include data, data records, or other information about bills that are to be 
presented to consumers 18 for payment. Information in biller data 23 may include, 
for instance, consumer names, statement numbers, statement dates, account 
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numbers, addresses, data about items or services provided or sold, amount due, 
billing history, marketing and / or advertising data, and any other information, 
whether in the form of text, graphics, audio, video or any alternative multimedia 
content, that billers 12 desire to present to consumers 18. Biller data 23 can be 
5 according to AFP, Metacode, Line Data (ASCII or EBCDIC for example), PCL, 

DJ/DE, OFX, XML, or any other format or protocol, whether print stream, electronic 
data interchange, or otherwise. 

Input processing engines 22 may be adapted to support any of these 
standards, in order to transform biller data 23 into a form and format suitable for 

10 processing by rules based parsing engine 24. Input processing engine 22 may be 
implemented using an Oracle Parallel Server running on a clustered Sun platform, 
for example, or according to any other desired implementation. The main concept is 
to modularize the preprocessing of biller data 23; if a new form of biller data 23 is 
encountered or must be dealt with for transformation into a form and format usable 

15 by rules based engine 24, then a new input processing engine is built to handle that 
data in a modular way. The preprocessing of AFP, for example, is different than 
preprocessing of metacode, so it makes more sense to have a separate engine 22 
for each, so that the output of each is ready for processing by rules based parsing 
engine 24. Preprocessing of various types of biller data 23 is done in the same sort 

20 of conventional way that print streams or other financial or EDI data streams are 
processed or converted for various purposes. It may be that some biller data 23 
does not need to be preprocessed, in which case there may be no need for an input 
processing engine for that data 23. 

Rules based parsing engine 24 allows a wide variety of biller data 23 types 

25 and formats to be operated on or parsed by rules in order to fit a common document 
or data model which can store and process both data and its attributes. In other 
words, it is important for the common data or document model to know not only an 
account number being stored, but also that it is an account number and not a bill 
number or date. The parsing engine 24 helps progress data 23 toward a form or 

30 format according to which both the data and its attributes can be known, stored and 
processed. It does not matter if rules engine 24 outputs a tight set of data and tags 
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or other corresponding attributes, or if that is done later; the parsing engine 24's 
main task is to accept a wide variety of data 23 from various billers and put it into a 
form and format where it is at least easier to generate and correlate the attributes for 
various data in a form that can be used by the common document or data model. 
5 The rules used in parsing engine 24 are in turn preferably written using a 

uniform rules definition language. That URDL 25 seeks to allow a technician to take 
a new form of bifler data 23 and write rules to parse that data 23 without extenuating 
work or investment of time. For example, URDL 25 currently in use allows 
technicians to write a set of rules for new data presented by a new biller in several 

10 days, without the need for people who are more deeply immersed in the whys and 
wherefores of financial data interchange. URDL 25 instead seeks to institutionalize 
that financial data interchange knowledge by writing a language using certain 
syllogisms, algorithms, inferences and conclusions to be formed upon encountering 
various data types, certain realities about what the common document model / data 

15 model needs to have in the form of data and attributes, and allowing a technician 
merely to apply what is written in the language in a more mechanistic fashion to 
cause proper parsing to happen. The language is written using conventional 
knowledge about various print streams and electronic data interchange formats, 
knowledge about the common document model / data model, and techniques often 

20 applied to simplify preparation of various forms of data and its attributes to fit desired 
situations, such as text to be presented attractively in HTML, or data to be 
transacted on usefully in the form of XML data. Parsing engines 24 based on URDL 
25 are thus advantageous because they can allow parsing of billing streams without 
the need to develop new application program interfaces or other functionality that 

25 requires overemployment of skill or time. Parsing engine 24 may also be 

implemented using an Oracle Parallel Server running on a clustered Sun platform. 

As an example of what parsing engine 24 does, it may be adapted to parse 
relevant biller data 23 from each data record in a billing data stream based on 
instruction sets created to: identify individual data records within the input billing 

30 streams; locate, extract, and validate the relevant billing data within each data 

record; and assign meaningful attributes to the relevant billing data. Parsing engine 

20 


BNSCOCID: <WO.... 


0177938A2,L> 


WO 01/77938 


PCT/US01/10138 


24 may output the relevant billing data and corresponding meaningful attributes 
ultimately for storage in database 26 (after further processing) and for further 
processing by presentation processor 28 and payment processor 30. 

Figure 3 shows a more detailed diagram of functionality that processes biller 
5 data 23 and stores it in database 26 according to a common document model / data 
model. The broad idea that Figure 3 seeks to convey is the notion of modularity in 
taking various types of biller data 23, preprocessing where necessary, and parsing 
according to rules in parsing engine 24 (which may but need not be done according 
to a URDL 25), in order to place that biller data 23 in the form of a common 

10 document model tree. Think of the common document model / data model 

according to the present invention as a list of every field of data, and its attribute 
(such as, for example, bill number and tag denoting bill number) that could occur in 
any bill desired to be presented by any biller. Not every biller's biller data 23 or bill 
will have all of that information; instead, it only as a subset of all data and attributes 

15 which could be accommodated by the common document model / data model. 
Accordingly, the biller's subset, which contains data and attributes which can be 
stored and processed according to the model, but not all of them, is known as the 
common document model / data model tree 38. Tree 38, or fairly close to it, is the 
output of parsing engine 24. Database loader 40 then takes tree 38 and loads it 

20 efficiently, effectively, and in conventional fashion in the same sort of way various 
subsets of data are loaded, for example into a global XML data model, onto 
database 26 which is structured according to common document model / storage 
models of the present invention. 

Figure 4 shows processing of biller data 23 into form suitable for storage and 

25 use according to common document models / data models according to a preferred 
embodiment of the invention at a deeper level. Biller # 1 shown in Figure 4 presents 
a text stream of biller data 23 to be accommodated to platform 10 according to a 
preferred embodiment of the present invention. That text stream does not happen to 
require preprocessing, but instead is operated on directly by parsing engine 24A 

30 which applies an instruction set written in URDL 25. The instruction set was quickly 
and conveniently prepared by a technician to transform biller data 23 to conform to 
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common document model tree #1 (38A), which is biller #1 's biller data 23 
transformed into a subset of data and its attributes which conform to the common 
document model / data model used in platform 10. Biller #2's data is in AFP, an 
IBM print stream format which requires some preprocessing and text extraction 
5 before it is suitable for parsing by parsing engine 24B. Again, parsing engine 24B 
applies an instruction set which was specially prepared with minimum effort and 
specialized knowledge. After parsing, biller #2's data is in the form of common 
document model tree #2 (38B). The biller data 23 for Biller #3 and Biller #4 also 
require preprocessing and text extraction, as shown in Figure 4, although it fs not 

10 necessarily the case that any or all biller data 23 in AFP, metacode or otherwise will 
always or invariably require or not require preprocessing, text extraction or anything 
else to be operated on by parsing engine 24. If desired, for example, preprocessing, 
text extraction and other operations on biller data 23 could be accomplished in 
parsing engines 24. Modularity is preferred but not necessary according to the 

15 present invention. 

Figure 5 continues from Figure 4 to show loading of data and its attributes 
from common document model trees 38 A - D into database 26 for biller #'s 1 - 4. 
Again, the preferred paradigm is modular, even if not necessary. For example, 
separate database loaders 40 can be used, each with its own special rule set 39 to 

20 accommodate a particular biller, but one or fewer loaders 40 could be used with 
separate rule sets 39, or one or fewer loaders 40 with one or fewer (even if bigger) 
rule sets 39. Loaders 40 take the data and its attributes in common document 
model trees 38 A - D and load it efficiently and effectively into database 26, thus 
loading subsets of common document model / data model into storage according to 

25 the model itself. 

Figure 6 shows the presentment side of a preferred embodiment of electronic 
bill presentment and payment systems and processes of the present invention. The 
broader concept is that data and its attributes stored according to a common 
document model / data model in a database 26 according to the present invention is 

30 in a lingua franca that allows it to be transformed into electronic bills anywhere and 
everywhere, however desired by the biller 12 or the customer 18. In a preferred 
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embodiment, output from the database 26 is in a form of XML or its equivalent or 
successor, which allows that data to be handled by any platform or application 
anywhere. 

In Figure 6, two presentment processors 42 happen to be used. Any number 

5 could be used. Presentment processors 42 and 44 may be adapted to communicate 
with database 26 to retrieve, store, and modify common document model / data 
model information. Processor 42 is simply in the form of an XML style sheet which 
allows the data to be presented in whatever manner and to appear however and 
wherever desired by a biller 12 or customer 18. For instance, a style sheet that 

10 works with a billing interface 48 supported on Yahoo will be different from the style 
sheet that supports a billing interface 48 supported on AOL. Where the bill is to be 
presented on a customer's Quicken application or to a financial institution where 
OFX is the format, the processor 44 transforms the XML data and attributes into 
OFX for presentment. Again, the data whether in HTML, OFX or any other format, 

15 can be distributed over infrastructure 21 which is any kind of public or private packet 
switched, circuit switched, or wireless infrastructure. Presentment processors may 
be prepared for any sort of data format, and it is important to note that systems and 
processors according to the present invention give the biller 12 control over 
processors 42 and 44 in order to control how their bills will look and feel wherever 

20 presented. 

Platform 10 can enable billers 12 to exercise substantial management and 
administrative control over the electronic bill presentment and payment process. 
Platform 10 may provide billers 12 with an interface to database 26 and presentation 
processors 42 and 44, which may enable billers 12 to manage the administrative 

25 functions of electronic billing. The biller interface may enable billers 12, including 
employees and agents of billers 12, to perform a variety of administrative, customer 
service, management, and quality control functions. For instance, the biller interface 
may enable billers 12 to perform the, following functions: view current and previous 
consumers bills, view payment history, view consumer emails, modify consumer 

30 enrollment, verify consumer identity, confirm consumer enrollment, perform 

consumer account maintenance, associate accounts to a consumer, make payment 
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adjustments, change employee access permissions to the biller interface, send news 
and messages to consumers, associate accounts to news, perform online consumer 
statistics, create payment settlement and periodic reports, select manual billing, view 
selected bills, perform quality feedback updates, print quality assurance reports, and 
5 release bills for publishing. 

System embodiment 10 may also enable billers 12 to perform a variety of 
marketing functions via the biller interface. For example, the biller interface may 
enable billers 12 to create virtual groups. Virtual groups are market segments of the 
class of consumers 18 identified by billers 12 based on specific marketing rules. 
10 Billers 12 may use virtual groups to send emails to a portion of consumers 18 or to 
send marketing promotions to specific groups of consumers 18. Alternatively, the 
biller interface may enable billers 12 to use virtual groups to send any intelligent 
messaging to consumers 18. 

Figures 7 - 32 show a series of web pages for a preferred embodiment of a 
15 biller interface supported by platform 1 0 according to a preferred embodiment of the 
present invention. These screen shots are exemplary only; currently they are 
implemented in HTML but they or any interface to platform 10 may be implemented 
in whatever desired matter according to technology current or conventional as of the 
date of this document or later technology. In any event, Figure 7 shows a web page 
20 that enables billers 12 to access platform 10 by entering a login name and 

password. After billers 12 are authenticated, platform 10 enables billers 12 to 
perform a number of functions for managing electronic bill presentment and 
payment, such as system administration, reporting management, quality control, 
operations management, marketing, and customer service. For instance, Figures 8 - 
25 10 show a series of web pages that enable billers 12 to administer and manage an 
electronic bill presentment and payment program. As shown in Figure 8, billers 12, 
including employees and agents, may select a user logon ID, which may be used for 
tracking administrative transactions, to gain access to the administration services 
and for other desired purposes. As shown in Figure 9, billers 12 may create new 
30 users that may access the administrative functions by creating a user profile, which 
contains information such as user logon, user password, employee name, employee 
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telephone, and user group, such as quality assurance, customer service, or 
payment. Billers 12 may also control what administrative functions a user is 
permitted to perform on platform 10 by assigning the user to one of a number of 
predefined user groups each having different access parameters. 

In the preferred embodiment, billers 12 may also use the biller interface to 
configure and modify a customized electronic bill presentment and payment solution 
by controlling a number of parameters, such as general parameters, enrollment 
parameters, parsing and loading parameters, bill presentment parameters, payment 
parameters, and reporting parameters. Figures 10A - 10J show a series of web 
pages that enable billers 12 to customize an EBPP solution. For example, as shown 
in Figure 10A, billers 12 configure general billing parameters, such as biller currency, 
such as US dollars, date format, whether multiple accounts will be permitted, 
whether consolidation will be permitted, and what type of consolidation will be 
permitted. Billers 12 may also specify any number of document control parameters. 
As shown in Figures 10B - 10E, billers 12 may also configure enrollment 
parameters. For example, billers 12 may define the facilities that are permitted 
during trial periods, the number of trial cycles per account, and customer access 
options. Figure 10E shows a web page that enables billers 12 to define parsing and 
loading parameters, such as the type of print stream that is provided to platform 10 
and the frequency with which the billing stream will be provided to platform 10. 
Figure 10F shows a web page that enables billers 12 to modify and configure bill 
presentment parameters. For instance, billers 12 may control the appearance of 
electronic bills by defining different bill presentment templates based on criteria such 
as the type of banner, customer news, bill news, account page, and menu 
placement and positioning. Billers 12 may also control the method customers use to 
pay bills. As shown in Figures 10G - 101, billers 12 may enable consumers to pay 
bills either by direct debit or credit card, such as Visa, Master Card, Amex, and 
Discover. Figure 10J shows a web page that enables billers 12 to define channel 
and frequency parameters for settlement reports, activation reports, and taxation 
reports. 
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In the preferred embodiment, the biller interface to platform 10 also enables 
billers 12 to manage an electronic bill presentment and payment quality assurance 
program. Figure 1 1 shows a web page that enables billers 12 to review a particular 
type of bill or an entire bill batch, such as all bills that have recently been published. 
5 The bills may be selected manually by account number, randomly, or based on a 
particular virtual group and group ID. Figure 12 shows a web page that enables 
billers 12 to select and view various biller accounts. Billers 12 may also use the 
biller interface to release bills for publishing, as shown in Figure 13, and request bill 
consolidation, as shown in Figures 14A and 14B. 
10 As shown in Figures 1 5 - 1 8, the preferred embodiment of the biller interface 

also enables billers 12 to manage an electronic bill presentment and payment 
operations center. As shown in Figures 15 and 16, billers 12 may control inbound 
documents received from consumers. The documents may be identified by 
document number, document type, status, and the date and time they were 
15 received. Billers 12 may also control outbound documents in a similar manner, as 
shown in Figures 17 and 18. 

Figures 19 - 21 show a series of web pages that enable billers 12 to manage 
communications with consumers. As shown in Figure 20, billers 12 may send mass 
email messages to consumers reminding them of overdue payments, welcoming 
20 them to the EBPP program, or notifying them of new bills. Billers 12 may also 

compose and deliver to consumers news messages, such as marketing messages, 
banner messages, biller messages, and account messages. 

The preferred embodiment of the biller interface also enables billers 12 to 
manage electronic bill presentment and payment marketing functions. For instance, 
25 as shown in Figure 22, billers 12 may perform virtual group maintenance, including 
creating new virtual groups, deleting existing virtual groups, and linking virtual 
groups. Figure 23 shows a web page that enables billers 12 to edit virtual groups by 
modifying existing conditions, fields, operations, and value parameters or by adding 
additional virtual group rules, such as those described above. 
30 As shown in Figures 24 - 32, billers 12 may also use the biller interface to 

support a customer service program. Figure 24 shows a web page that enables 
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billers 12 to view customer bills in the exact form as they are delivered to and viewed 
by consumers, which provides customer service representatives a significant benefit 
in resolving customer service requests. As shown in Figure 25, billers 12 may also 
view, activate and deactivate biller accounts. Billers 12 may also view customer 
5 information related to customer profiles, customer agreements, customer payment 
instruments, and scheduled payments. Billers 12 may send email messages to a 
customer mailbox residing on platform 10. In addition, as shown in Figure 32, 
billers 12 may monitor the status of customer service requests by creating and filing 
customer service notes, which may include information such as account number, 
10 subject of customer service request, action date, and whether or not a follow up is 
required. 

System embodiment 10 also supports consumers 18 receiving electronic bills 
at any location of choice using any interface, such as, for instance, a conventional 
web browser, other online device, any wireless device, or any other device which 

15 may communicate with system embodiment 10 in any manner. Any such device is a 
candidate to support presentation of or transaction with platform 10 by consumers 
18. Consumers 18 can also define the format of the electronic billing information. 
For example, the billing data may be supplied to consumers 18 in a variety of 
standard accounting formats. System embodiment 10 also enables consumers 18 

20 to pay electronic bills via credit card, ACH, or electronic funds transfer or using any 
other mode or medium of payment or reconciliation. 

Figure 33 is a functional diagram that shows functionality and services 
supported by platform 10 according to a preferred embodiment of the present 
invention. Surrounding the common document model / data model database 

25 functionality denoted as common services 100 in Figure 33 are the input processing 
engine 102, biller interaction management 104, payment gateway and interface 
management 106, financial institution payment gateway 108, payment functionality 
110, targeted marketing functionality 112, presentment and distribution management 
114, biller console 116, e-mail interaction management 1 18 and customer 

30 service and interaction management 120. Any or all of these can couple to 

database 26 (common services 110) data and data attributes to accomplish their 
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purposes, using a lingua franca such as XML. Thus, billers do not lose control over 
their data once it is "launched" over to the platform 10; instead, biller may, among 
other things: 

a. control parsing rules in the input processing engine 102 to 
5 accommodate virtual groups according to virtual group functionality 112; 

b. interact with customers while seeing their billing records, using 
customer service and interaction management functionality 120; 

c. control how bills or reminders are sent to customers using e-mail, using 
functionality 118; 

10 d. control appearance and other characteristics of bill presentment in real 

time using presentment and distribution relationship management functionality 114; 

e. get reports and otherwise control the billing process (including for 
example, obtaining parsing reports, getting account receivable information or feeds, 
stopping or starting print or enrollment, and other tasks) using biller interaction 

15 management 104; 

f. support its own website for presentment and payment of bills; and of 
course 

g. get paid via payment functionality 110. 

From a customer's point of view, his or her bills can be supported anywhere, 
20 and customers are allowed additional communications with billers via e-mail 
interaction management 118 and interfaces 122. 

Financial institutions (or any other entity, such as payment facilitators or other 
EBPP operations) are connected and can transact with their customers (who also 
happen to be biller's customers) more efficiently and effectively through various 
25 gateways and other interfaces. Indeed, financial institutions may if desired, fit within 
the category of billers, and be connected the in the same or similar manner, to 
accomplish the same sorts of enhanced contact with their customers to conduct 
electronic commerce, which may include presentment and payment of bills. 

This diagram is merely logical; any of these functionalities can reside within 
30 other functionalities, and not all of them need to be included to carry out various 

purposes or results obtained by the present invention. Furthermore, the connections 
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to the functionalities and between them are logical; billers may be connected via bus 
or to only one biller interaction functionality in order to carry out some or all of the 
control that systems and processes according to the present invention could allow. 
Figure 34 shows merely one example of how EBPP systems and processes 

5 according to the present invention can connect to accommodate the interests of 
various parties in an electronic commerce context. Here a system 11 
accommodates an insurance company and its agents. Sometimes agents 152 are 
the ones who get the premium checks, but more usually the insurance company 
gets the check or premium payment via direct deposit. But the agents get paid on 

10 commission from the company 150, and they want to have continual access to 
payment status on all their customers. EBPP system 1 1 allows this to occur by 
connecting the agent 152 and the company 150 to the EBPP system 1 1 via agent 
console or interface 156, the company 150 in the context of a biller 12. Payment 
can occur via check, or other forms of payment supported by EBPP system 1 1 

15 through financial institutions 12, facilitators 16, credit organizations, or otherwise. 
The customer pays the bill which has been presented anywhere according to any 
desired format and the wishes of the insurance company. Immediately the 
insurance company 1 50 and the agent 152 know the bill has been paid. The agent 
can be paid his or her commission via system 11 if desired. The system 1 1 is 

20 particularly useful for policies that cover multiple insureds or lines of insurance; the 
company and the employer can access, according to preset permissions, the 
database 26 and drop employees who have left, for example, or add new employees 
to the coverage, and can add, drop or modify lines of insurance easily and quickly. 
Figures 35 - 65 show a series of web pages for an agent console 156 

25 according to a preferred embodiment of systems and processes of the present 

invention. In the preferred embodiment, agent console 156 enables an agent of a 
company, such as an insurance agent or any other agent of a company, to access 
information related to customers, communicate with the company and customers, 
and conduct electronic business transactions with the company and customers. The 

30 information may be related to customer payment status, customer profiles, customer 
policies, or any other information associated with the relationship between the agent, 
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the company, and customers. Figure 35 shows a web page that enables an agent 
to access EBPP system 1 1 by entering a login name and password. After the login 
name and password are authenticated against a database within system 1 1, the 
agent gains access to system 11. 

Figures 36 - 59 show a series of web pages that enable an agent to perform 
customer account management services. For example, an agent may search for 
customer account information based on policy number, as shown in Figure 36, or 
based on customer name, as shown in Figure 37. Figure 38 shows a web page that 
displays customer account information for a particular policy number that has been 
queried by an agent. An agent may view the payment history for the customer, view 
the customer policy and payment schedule, make payments to the company for the 
customer, or send electronic messages to the customer. Figure 39 shows the linked 
web page that displays the payment history information for a customer, which 
contains a list of each transaction and related information, such as the date of 
payment, amount of payment, the transaction number, the authorization number, 
payment status, and the customer reference number. Figures 40A and 40B show 
the linked web page that enables an agent to view a customer policy and make 
policy payments. For instance, Figure 41 shows the linked web page that enables 
an agent to view customer payment information and the electronic bill. Figures 42 
and 43 show the linked web pages that enable an agent to select the type of 
payment parameters for the transaction. For example, an agent may select how 
much of the amount due to apply to the transaction and the type of payment, such 
as by electronic check, credit card, cash, money order, or any other suitable 
payment method. If the customer desires to pay via electronic check, the agent may 
also select the type of account, such as checking or savings. Figure 44 shows a 
web page that enables an agent to send a note to a consumer on a personalized 
mailbox, which resides on platform 10 of system 11. 

As mentioned above, an agent may also search for customer account 
information based on customer name. Figure 45 shows a web page that enables an 
agent to select the appropriate customer from the search result list. Figure 46 
shows a linked web page that displays the customer account information and 
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enables an agent to view the payment history for the customer, view the customer 
policy and payment schedule, make payments to the company for the customer, and 
send electronic messages to the customer. 

The preferred embodiment of agent console 156 also enables efficient 
5 payment of multiple policies associated with one individual, company or other 
insured entity. For example, as shown in Figure 47, an agent may search for an 
individual with multiple insurance policies. Figure 48 shows a web page that 
displays the search results and enables an agent to select multiple policies for the 
same individual that the agent desires to pay. Figure 49 shows a web page that 

10 displays the policy and account information for each policy, including the policy 

number, amount due, date due, amount to be applied, and the payment type, such 
as electronic check, money order, credit card, or cash. After the agent configures 
the payment parameters, as shown in Figure 50, payment may be made and applied 
to the respective accounts. As shown in Figure 51, system 1 1 may provide the 

15 agent with verification that the desired operation was successful. 

As shown in Figure 52, an agent may also access customer account 
information by viewing a list of current policies. Figures 53A and 53B show a linked 
web page that enables an agent to view policy information for a selected customer 
and make payments for the customer as described above. 

20 In addition to the customer management services mentioned above, an agent 

may create new policies. Figure 54 shows a web page that enables an agent to 
configure a new policy profile, including information, such as customer name, policy 
number, type of policy, such as an automobile, home or life insurance policy, 
payment cycle, and the amount of a current payment. As shown in Figures 55 - 57, 

25 the agent may also make initial payments for the new policy in the same manner as 
describe above. 

An agent may also, at any time, create and view customer notes. The agent 
may use the customer notes for managing customer service. For example, as 
shown in Figures 58 and 59, an agent may create a customer note reminding the 
30 agent to call a customer on a particular date to discuss a billing inquiry matter or any 
other customer service matter. 
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In addition to the customer management services described above, the 
preferred embodiment of agent console 156 also enables an agent to efficiently 
manage the agency relationship with the company. Figures 60 -65, show a series of 
web pages that enable an agent to process and view cash reports and customer 
payment reports, make payments to the company, and manage agent commissions 
for services performed for the company. Figure 60 shows a web page that enables 
an agent to select a time period and view agent transaction reports for that time 
period. Figure 61 shows a linked web page that displays information related to each 
agent transaction that occurred during the time period, such as policy number, 
payment instrument and the amount paid to the agent, and an account summary, 
which may include information such as account balance, agency payments made, 
and amount owed to the company. As shown in Figure 62, the agent may also 
make payment to the company. Figures 63 and 64 show a web page that enables 
an agent to select parameters for the payment to the company. 

The preferred embodiment of agent console 156 also enables an agent to 
perform a number of reporting functions related to customer receipt information and 
payments made to the company. As shown in Figure 65, an agent may view, print 
and process receipt reports based on time period and payment type, such as cash, 
money orders, credit card, and checks. An agent may also view, print, and process 
reports of all transactions with the company. 

Figure 66 shows the potential for leveraging the power of systems and 
processes according to the present invention to create and use virtual groups of 
customers for purposes of customer relationship or brand building. As shown in 
Figure 66, rules may be applied to data and data attributes of customer information, 
bill information, or any other desired information in order to classify or categorize 
customers, bills, or any other metadata or data stored in database 26. The virtual 
group may be used to alter the appearance of bills to include various content, to time 
delivery of the bill, to customize the bill according to certain time sensitive events, or 
otherwise to engage in target based marketing as it relates to bill presentment. The 
virtual groups can also be used to give certain incentives to those who pay regularly 
or who regularly pay large bills, such as applying discounts or assigning customer 
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service reps, or awarding frequent user points. The rules may be applied at the 
parsing stage, at the presentment stage or any other desired point in the EBPP 
processes carried out by the present invention. The opportunities to use the virtual 
groups are unlimited; power companies can leverage from their billing base stored 
5 on database 26 combined with virtual groups to inform customers via e-mail in zip 
code 30327 that their power will be off from 4 to 4:30 or that power will be 
discounted during certain portions of the day, for example. The virtual group 
functionality may accordingly interact not only with the database 26, but also with 
any desired functionality shown in Figure 7. 

10 The foregoing is provided in order to disclose the invention in accordance with 

the patent laws, and more particularly to disclose preferred embodiments of systems 
and processes according to the present invention. Modifications, adaptations, and 
changes may be made to what is disclosed without departing from the scope or spirit 
of the invention, which is to provide EBPP systems and process which use a 

15 common document model / common data model into which biller data from a wide 
range of billers fits, in order to allow billers to outsource the billing responsibility to an 
EBPP organization while retaining control over and access to their data and the 
billing process, and accommodating the interest of customers, financial institutions 
and other parties as well. 
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CLAIMS 

What is claimed is: 

1. A system for presenting and paying bills, comprising: 

5 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 
programmed, corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; 

b. a common document model processing functionality adapted to 

10 transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

15 d. presentation functionality adapted to retrieve information from said 

database and output at least some of said information via a network for use by bill 
payers. 

2. A system according to claim 1 in which the parsing functionality is adapted to 
20 parse data from a print stream of data provided by a biller. 

3. A system according to claim 1 in which the parsing functionality is adapted to 
parse data from a data interchange stream of data provided by a biller. 

25 4. A system according to claim 1 in which the parsing functionality is adapted to 
parse data from a financial data stream provided by a biller. 

5. A system according to claim 1 in which the presentation functionality is 
adapted to output information for use by bill payers using financial software. 

30 
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6. A system according to claim 1 in which the presentation functionality is 
adapted to output information for use by bill payers not using financial software. 

7. A system according to claim 6 in which the presentation functionality is 
5 adapted to output information for use by bill payers using a browser. 

8. A system according to claim 1 in which the presentation functionality employs 
style sheet functionality in order to render information in a form suitable for bill 
payers. 

10 

9. A system according to claim 6 in which information is provided to bill payers 
using markup language. 

10. A system for presenting and paying bills, comprising: 

15 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 
programmed, corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; 

b. a common document model processing functionality adapted to 

20 transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

25 d. presentation functionality adapted to retrieve information from said 

database and output at least some of said information via a network for use by bill 
payers; and 

e. an interactivity functionality adapted to detect and respond to 
communications from a bill payer, by at least (i) retrieving information from said 
30 database and presenting it to said bill payer in a form requested by said bill payer; 
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and (ii) altering information in said database corresponding to said bill payer 
according to said communications. 

11. A system for presenting and paying bills, comprising: 

5 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 
programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 

10 transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

15 d. presentation functionality adapted to retrieve information from said 

database and output at least some of said information via a network for use by bill 
payers; and 

e. interactivity functionality adapted to detect and respond to 
communications from a biller, by at least retrieving information from said database 
20 corresponding to said biller and presenting it to said biller in a form requested by 
said biller. 

12. A system according to claim 1 1 further comprising interactivity functionality 
adapted to detect and respond to communications from a bill payer, by at least (i) 

25 retrieving information from said database and presenting it to said bill payer in a form 
requested by said bill payer; and (ii) altering information in said database 
corresponding to said bill payer according to said communications. 

13. A system for presenting and paying bills, comprising: 

30 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 
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programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 

5 document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

d. a presentation functionality adapted to retrieve information from said 
10 database and output at least some of said information via a network for use by bill 

payers; and 

e. a biller interface coupled to said database adapted to allow a biller to 
alter appearance and content of bills presented to bill payers. 

15 14. A system according to claim 13 in which the biller interface is further adapted 
to allow the biller to communicate with bill payers regarding bills. 

15. A system according to claim 13 further comprising interactivity functionality 
adapted to detect and respond to communications from the biller, by at least 

20 retrieving information from said database corresponding to said biller and presenting 
it to said biller in a form requested by said biller. 

16. A system according to claim 13 further comprising interactivity functionality 
adapted to detect and respond to communications from a bill payer, by at least (i) 

25 retrieving information from said database and presenting it to said bill payer in a form 
requested by said bill payer; and (ii) altering information in said database 
corresponding to said bill payer according to said communications. 

17. A system for presenting and paying bills, comprising: 

30 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the extractor is programmed, said 
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billing data corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; 

b. a common document mode! processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c- a database adapted to store the transformed information from the 
common document model processing functionality; and 

d. presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers; and 

e. a financial source interface adapted to send and receive 
communications to and from at least one financial entity and to alter information in 
said database according to said financial source communications. 

18. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules according to which the extractor is programmed, said 
billing data corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate relevant information from the plurality 
of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

d. a presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers; 

e. interactivity functionality adapted to detect and respond to 
communications from a bill payer regarding at least one of said bill payer's bills 
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presented by said system, by at least (i) retrieving information from said database 
and presenting it to said bill payer in a form requested by said bill payer; and (ii) 
altering information in said database corresponding to said bill payer according to 
said communications; and 

f. a financial source interface adapted to send and receive 
communications to and from at least one financial entity based at least in part on 
communications from said bill payer and to alter information in said database 
corresponding to said bill of said payer, according at least in part to said financial 
source communications. 

19. A system according to claim 18 further comprising interactivity functionality 
adapted to detect and respond to communications from a biller, by at least retrieving 
information from said database corresponding to said biller and presenting it to said 
biller in a form requested by said biller. 

20. A system according to claim 18 in which said interactivity functionality is 
adapted to report information to billers relating at least to status of payment on their 
bills presented by said system. 

21. A method of providing electronic bill presentment and payment services, 
comprising the steps of: 

a. extracting relevant information from billing data, corresponding to a 
plurality of data types, from a plurality of billers using rules; 

b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 
information from the plurality of billers and according to the plurality of data types; 

c. storing the transformed information from the common document model 
in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers. 
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22. The method of claim 21 in which said billing data is from a print stream of 
data provided by a biller. 

23. The method of claim 21 in which said billing data is from a data interchange 
5 stream of data provided by a biller. 

24. The method of claim 21 in which said billing data is from a financial data 
stream provided by a biller. 

10 25. The method of claim 21 in which said at least some of said information is 
output for use by bill payers using financial software. 

26. The method of claim 21 in which said at least some of said information is 
output for use by bill payers not using financial software. 

15 

27. The method of claim 21 in which said at least some of said information is 
output for use by bill payers using a browser. 

28. The method of claim 21 in which said at least some of said information is 

20 output using style sheet functionality in order to render information in a form suitable 
for bill payers. 

29. The method of claim 26 in which said at least some of said information is 
provided to bill payers using markup language. 

25 

30. A method of providing electronic bill presentment and payment services, 
comprising the steps of: 

a. extracting relevant information from billing data, corresponding to a 
plurality of data types, from a plurality of billers using rules; 
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b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 
information from the plurality of billers and according to the plurality of data types; 

c. storing the transformed information from the common document model 
5 in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers; and 

e. detecting and responding to communications from a bill payer, by at 
least (i) retrieving information from said database and presenting it to said bill payer 

10 in a form requested by said bill payer; and (ii) altering information in said database 
corresponding to said bill payer according to said communications. 

32. A method of providing electronic bill presentment and payment services, 
comprising the steps of: 

15 a. extracting relevant information from billing data, corresponding to a 

plurality of data types, from a plurality of billers using rules; 

b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 
information from the plurality of billers and according to the plurality of data types; 
20 c. storing the transformed information from the common document model 

in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers; and 

f. detecting and responding to communications from a biller, by at least 
25 retrieving information from said database corresponding to said biller and presenting 

it to said biller in a form requested by said biller. 

33. A method of providing electronic bill presentment and payment services, 
comprising the steps of: 

30 a. extracting relevant information from billing data, corresponding to a 

plurality of data types, from a plurality of billers using rules; 
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b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 
information from the plurality of billers and according to the plurality of data types; 

c. storing the transformed information from the common document model 
5 in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers; and 

e. allowing a biller to alter appearance and content of bills presented to 
bill payers. 

10 

34. The method of claim 33 further comprising the step of allowing the biller to 
communicate with bill payers regarding bills. 

35. A method of providing electronic bill presentment and payment services, 
15 comprising the steps of: 

a. extracting relevant information from billing data, corresponding to a 
plurality of data types, from a plurality of billers using rules; 

b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 

20 information from the plurality of billers and according to the plurality of data types; 

c. storing the transformed information from the common document model 
in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers; and 

25 e. sending and receiving communications to and from at least one 

financial entity and altering and storing information according to said 
communications. 

36. , A method of providing electronic bill presentment and payment services, 
30 comprising the steps of: 
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a. extracting relevant information from billing data, corresponding to a 
plurality of data types, from a plurality of billers using rules; 

b. transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 

5 information from the plurality of billers and according to the plurality of data types; 

c. storing the transformed information from the common document model 
in a database; and 

d. retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill payers; 

10 e. detecting and responding to communications from a bill payer 

regarding at least one of said payer's bills presented by said system, by at least (i) 
retrieving information from said database and presenting it to said bill payer in a form 
requested by said bill payer; and (ii) altering information in said database 
corresponding to said bill payer according to said communications; and 

15 f. sending and receiving communications to and from at least one 

financial entity based at least in part on communications from said bill payer and to 
alter information in said database corresponding to said bill of said bill payer, 
according at least in part to said communications. 

20 37. The method of claim 36 further comprising the step of detecting and 

responding to communications from a biller, by at least retrieving information from 
said database corresponding to said biller and presenting it to said biller in a form 
requested by said biller. 

25 38. The method of claim 36 further comprising the step of reporting information to 
billers relating at least to status of payment on their bills presented to said system. 

39. A system for presenting and paying bills, comprising: 

a. an extractor functionality which is adapted to parse billing data from a 
30 plurality of billers using rules according to which the extractor functionality is 
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programmed, corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; and 

d. presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers; and 

e. a bill payer interface coupled to said database adapted to allow a bill 
payer to pay bills electronically. 

40. The system of claim 39 in which said interface is adapted to allow said bill 
payer to specify the location of said output. 

41. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules according to which the parsing functionality is 
programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; 

d. a presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers; and 
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e. a biller interface coupled to said database adapted to allow a biller to 
identify market segments of bill payers according to market rules and information 
retrieved from said database. 

5 42. A system according to claim 41 in which the biller interface is further adapted 
to allow the biller to alter appearance and content of bills presented to bill payers 
based on the market segments. 

43. A system according to claim 41 in which the biller interface is further adapted 
10 to allow the biller to send marketing messages to bill payers based on the market 

segments. 

44. A system according to claim 41 in which the biller interface is further adapted 
to allow the biller to communicate with bill payers regarding bills based on the 

15 market segments. 

45. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules according to which the parsing functionality is 

20 programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 

25 plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; 

d. a presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 

30 payers; and 
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e. interactivity functionality adapted to detect and respond to 
communications from a biller regarding market segments of bill payers by retrieving 
information from said database and altering appearance and content of bills 
presented to bill payers based on said communications. 

5 

46. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules according to which the parsing functionality is 
programmed, said billing data corresponding to a plurality of data types, and to 

10 provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 
document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

15 c. a database adapted to store the transformed information from the 

common document model processing functionality; 

d. a presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers; and 

20 e. interactivity functionality adapted to detect and respond to 

communications from a biller regarding market segments of bill payers by retrieving 
information from said database and sending marketing messages to bill payers 
based on said communications. 

25 47. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 

programmed, said billing data corresponding to a plurality of data types, and to 

provide relevant information for further use by said system; 
30 b. a common document model processing functionality adapted to 

transform said relevant information into a common document model, which common 
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document model is adapted to accommodate said relevant information from the 
plurality of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; 
5 d. a presentation functionality adapted to retrieve information from said 

database and output at least some of said information via a network for use by bill 
payers; and 

e. interactivity functionality adapted to detect and respond to 
communications from a biller regarding market segments of bill payers by retrieving 
10 information from said database and altering information in said database 
corresponding to bill payers according to said communications. 

48. A system for presenting and paying bills, comprising: 

a. parsing functionality which is adapted to parse billing data from a 
15 plurality of billers using rules according to which the parsing functionality is 

programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 
transform said relevant information into a common document model, which common 

20 document model is adapted to accommodate relevant information from the plurality 
of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; 

d. a presentation functionality adapted to retrieve information from said 
25 database and output at least some of said information via a network for use by bill 

payers; and 

e. an agent interface coupled to said database adapted to allow an agent 
having an agency relationship with a biller to communicate with bill payers regarding 
bills. 

30 
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49. A system according to claim 48 in which the agent interface is further adapted 
to allow the agent to communicate with the biller regarding bills of said bill payers. 

50. A system for presenting and paying bills, comprising: 

5 a. parsing functionality which is adapted to parse billing data from a 

plurality of billers using rules according to which the parsing functionality is 
programmed, said billing data corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

b. a common document model processing functionality adapted to 

10 transform said relevant information into a common document model, which common 
document model is adapted to accommodate relevant information from the plurality 
of billers and according to the plurality of data types; 

c. a database adapted to store the transformed information from the 
common document model processing functionality; 

15 d. a presentation functionality adapted to retrieve information from said 

database and output at least some of said information via a network for use by bill 
payers; 

e. bill payer interactivity functionality adapted to detect and respond to 
communications from a bill payer, by at least retrieving information from said 

20 database corresponding to said bill payer and presenting said information to said bill 
payer in a form requested by said bill payer; and 

f. biller interactivity functionality adapted to detect and respond to 
communications from a biller, by at least retrieving information from said database 
corresponding to said biller and presenting said information to said biller in a form 

25 requested by said biller. 

51. A system according to claim 50 in which the biller interactivity functionality 
and the bill payer interactivity functionality are further adapted to present 
substantially the same information to the biller and the bill payer in order to allow the 

30 biller to Interact with the billpayer regarding the same information. 
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